Management An equal voice in product decisions

The Product Engineer

You don’t need Product Managers. There. I said it.

If you work for a company that builds primarily consumer software1, there are, hopefully, three groups of humans who believe they are accountable for the product. They are:

  • Engineering. They build the product.
  • Design. No, they build the product.
  • Product Management. No, really… they build the product.

Do you see the issue? You have three different groups with different skill sets, each of whom firmly believes their decisions are the decisions that allow the product to exist. They are each directionally correct. You can build a good product in a perfect world where each constituency is equally capable of doing its job. This includes a complicated process where these constituencies capably disagree, debate, and learn from their differences.

Problem is, the world is not perfect, and you need to build great product. Now.

Disclaimers: For every hypothetical engineer, designer, and product manager that I’m about to implicate as incompetent, there is an equal number who are not just capable, they are an absolute inspiration. There are additional roles that I don’t discuss that are essential to your burgeoning product company. Quality, marketing, sales, support. They are essential, but that’s a different article.

Gosh, I want to describe all the interesting failing configurations of Engineering, Design, and Product Management that I’ve personally observed sucking the life out of a good product, but let’s start with the greatest hits:

Scenario #1: Product Managers as CEO. In this variant, your Product Managers think they are the CEO of the Product. If you think about this configuration as voting rights, the Product Managers would suggest — trying to be helpful and fair — that they’ll serve a tie-breaking vote when we can’t agree.

They honestly claim this voting structure not because they want all the power; they want to cast the tie-breaking vote when there is gridlock occasionally. And, ya’know, sometimes someone needs to decide, ya’know, just to keep moving things along.

Bullshit. They do want the power. These power structures are counter to great product design and development. They amplify individual opinions over the hard work of building great decisions. Those painful impasses where no one can agree? Those are hard-earned decisions that will make your product great. Yes, they are hard. Yes, it’ll feel like you’re wasting precious time swirling around a decision, but this is critical work. This is when you discover a feature’s truth, value, and essence.

Product Managers CEOs with the tie-breaking vote will eventually make unilateral decisions with insufficient cross-functional debate because they believe they are “moving us along”. They will do this precisely when you and your team could learn the most. They believe that because the title is Product Manager, they are the Product.

In my experience, the attributes I value in a good Product Manager are:

  • Understand the current feature set deeply and how new features complement and enhance the future product.
  • Can speak for the customer because they’ve taken the time to understand the customer deeply.
  • Know the critical decisions that were made that resulted in the current state of the product. They know what is broken and how it became so.
  • Are capable of making reasoned decisions and explaining their thinking to anyone.
  • Are curious and willing to learn about anything relevant to the product whether it’s their domain or not.

Scenario #2: Uncompromising Designers. If you want to trigger a designer, here’s a simple approach. Ask them, “Why are we spending so much time on this inconsequential color, typeface, layout, or other trivial thing?” At this moment, they hear three thoughts at the same time:

  1. “This person thinks my work is inconsequential.”
  2. “This person doesn’t understand that small bits of work elegantly and thoughtfully combined is the big thing elegantly working.”
  3. “This person believes that because the decision appears easy to make, it does not require work.”

Designers hear some small version of this critique a lot during their careers. When you combine this with the fact that Design teams are small relative to Engineering, they must choose their product design battles carefully. Often, after years of losing these battles to Engineers who belittle their craft as inconsequential or Product Managers who state product ideas as design ideas, these designers transform into the Uncompromising Designer.

These humans (or teams) politically move to an independent metaphoric island where design is produced. They then put this design on a little ship that travels to the mainland, where Engineering and Product Managers live. Designs are reviewed, commented on, and returned via the same little ship where wait for it, all feedback is ignored with the unspoken rationale, “They don’t understand what we’re trying to achieve. They aren’t on the island.” (Note: No one is ever invited to the island.)

In this nightmare scenario, Product Managers and Engineers are picking and choosing from the designs (without the Designers in the room — I’m not kidding — it’s terrifyingly common) and implementing random features based on an uninformed feel. Customers who see this haphazardly designed product think, “It looks kind’a like what I want to do, but I struggle to understand the product. I click… this?”

This is most software, I’m afraid.

Good designers I’ve worked with:

  • Understand that how a user feels about a product dramatically influences their use.
  • Are comfortable in the depth of their craft. They can deftly explain how their choices of layout, color, and typography affect the approachability of the product.
  • Will defer to their professional peers when the time is right after everyone’s been heard and if the winning argument is sound.
  • Obsesses about the details because the details work together to define how the user feels about the product.
  • Are curious. Willing to learn. Doesn’t matter if it isn’t their area of expertise.

Scenario #3: Disconnected Engineers. Our final failure case is a reaction to our prior two scenarios, and this is the primary scenario I want to discuss because, as an engineer, it’s the one I want to fix.

The Disconnected Engineer has spent the last six years of her life working to become a good engineer. This started in high school when she first discovered Python and saw computers as a tool for bringing ideas to life. Four years in college, becoming a computer scientist along with two internships, and now she’s hired into her dream: a full-time software engineer. A company she respects.

Problem is: Product Management thinks they’re the CEO, are drunk with power, and are adept at tossing impressively sounded bulleted lists over the fence to Design and Engineering. These lists have no context and littered with meaningless MBA-speak designed to sound official but do nothing to explain a coherent product strategy.

Meanwhile, over on the island, Design is musing about whatever the hell because they know those bullets from Product Management are whatever occurred in their last three meetings and have no strategy or substance. Design has heard we’re going to do Feature X and has produced stunning designs in a vacuum that will be delivered whenever the next ship leaves the island. Our engineer wants to engage with this design and discuss it, but Design is on that island far, far away.

Extend this passive-aggressive product-hostile situation over a few years, and our bright and eager Engineer becomes the Disconnected Engineer. The human accountable for building the product with their hands exists as a semi-motivated engineer who is grabbing bullets as they come over the fence and combining them with misaligned and misinformed design from the island, which results in strangely constructed features that… work. I mean, they look like features, but when I asked this engineer why she chose this approach, she said the thing that crushed my soul, “They told me to do it this way.”

Unacceptable.

The Product Engineer

I am not the first person to slap these two words together, but I want to introduce a concept of a different type of engineer: the Product Engineer.

As a starting framework, a Product Engineer:

  • Has a deep knowledge of how the product is built. If the product is not yet built, they can scribble how it should work on a whiteboard.
  • Able to explain to anyone with the motivation to understand how each product feature works. They are likely more knowledgeable regarding certain feature sets in larger products, but their understanding of the complete product is vast.
  • Actively use the product and report bugs when they happen upon them.

Do you know what bad product managers do to engineers (and designers)? They suck the air out of accountability. Their existence creates the impression that someone other than the human responsible for building the product with their hands is better at designing and building products. That someone else has a plan.

What?

Bad product managers are an active hindrance to developing software. This is the reason I’m picking on them in this piece. With no product management function, someone else must do the work, which organically falls on engineering and design. My definition of Product Engineer expands to include all the responsibilities of the Product Manager (and a little bit of Design).

A Product Engineer:

  • Uses the product every day and reports bugs aggressively when they find them.
  • Intimately knows how the products work and can explain any feature or inner workings to anyone. When they find a gap in their knowledge, they fill it.
  • Have a deep understanding of how users perceive their features and how their changes would affect their perception. They can wear the customer mindset.
  • Remember the debates around the most complex decisions and why we chose this path.
  • Have living breathing code in the product — right now.
  • Can effectively argue with anyone on the team regarding the product. Will defer to their team members when the argument is sound, but they will continue to argue until there is product clarity.
  • Communicates well in every direction because they’ve developed professional relationships in all those directions.
  • Are aggressively curious and willing to learn anything relevant to the design and development of the product, especially when it’s outside of their area of expertise.

A Product Engineer is accountable for the product.

Accountability is not responsibility. Accountability means you are required or expected to justify your actions and decisions. You are required to give an account to share the story of how we decided to build this feature, why we chose it over many other features, and how we iterated on subtle design tweaks for months to deliver what we believe is the best possible version.

Somebody Else’s Job

Any number of organizational configurations involving engineers, product managers, and designers can produce successful products. Over the past three decades, my observation is that the companies that have let the builders — the engineers and the designers — own significant parts of the role of Product Manager produce stronger products.

You want the humans building the product to have an equal voice in product decisions. You want the hard decisions to painfully earn their resolution through long hours of informed humans staring at the problem from every angle. You want humans who build.

And you don’t need Product Managers.

  1. If you build Enterprise Software, you need product managers. ↩
# 9 Comments on The Product Engineer
Management I thought I was doing ok, until I wasn’t

Ok. So, You’re Failing

Years ago at Borland. My first real gig. I was poached from an internship into a full-time QA gig. When I accepted the offer, they sent me a box of Borland schwag, t-shirts, notebooks, and pens. I was elated. No more hourly wages, I was full-time.

Six months in, my manager sat me down at her desk and slid a piece of paper over. She was quiet and, in hindsight, nervous. I read the paper and realized she was documenting how I had failed at my job. She asked me to sign the piece of paper I’d barely read.

I did. Next to my signature was a date. It wasn’t today; it was 90 days from today.

Disclaimers

I wrote a piece about performance management a few years back. This was entirely for managers. This piece is for the individual contributor on a performance plan, but I need to set two initial conditions to make this helpful.

First, there are bad managers who use performance management not to address a performance issue but to let go of an employee as quickly as possible. Sorry. These managers suck. For this article’s sake, we assume the manager intends to address the performance issue.

Second, I’m assuming this is a fixable situation. You are in a job you can do, and through a combination of your and your manager’s focused effort, it is possible to succeed.

The First Challenge: Acceptance

“I had no idea I was failing.”

I thought this when my manager slid the paper over to me. I’ve heard this when I was the manager, and I hear this over and over via the recap when my managers deliver a performance plan.

This is the overwhelming first reaction to a performance plan, and the contributing factors for this reaction are:

  • Humans really don’t like to give negative feedback. In fact, we’ve rebranded this type of feedback as constructive feedback because we are so profoundly uncomfortable delivering it. Because we avoid giving it early and often, this is likely the first time you’ve heard it in a focused and direct way.
  • Humans really don’t like to receive negative feedback. It’s a self-preservation thing. It’s pride. We effortlessly twist the story to hear the narrative that best suits our worldview.

Your first of four challenges is entertaining the idea that you can fail. You’re not going to wholesale believe this right now, but if you can’t consider the possibility of failing, you certainly won’t be able to address it.

The Second Challenge: Clarity

After your initial reluctant acceptance of the situation, the second challenge is clarifying the current state and remediations. Assuming you have a competent manager, this data should be sitting right in front of you in a written form, but here’s what you need to do, preferably during this first meeting:

  • Read the description of the situation. Forgetting your instinct to holler, “This is a total surprise” does the description make sense? Is it fair? Does it describe reality? If you declare, “Everything here is wrong, and this is a travesty,” you fail the first challenge. Clarifying misperceptions, adding critical missing data, and asking for more detail are the first healthy steps in resolving this situation, and they demonstrate your willingness to do so.
  • Read the expected next steps. This is a description of the work you need to complete. Like the description of the situation, the goal is understanding. What work do you need to complete? Is it obvious how success will be measured for these tasks? How often will we be meeting to review progress?
  • Finally, there’s that date at the end of the document. What does it mean? Delicate topic here because it could mean, “We’ll check-in on this date” or “This is when we’ll decide on your status at the company.” Understanding what this date means is critical data you need.

The time you take to review this document the moment it lands is essential. Yes, it’s okay to sleep on it and have additional questions later, but at this first moment, you are setting expectations with your manager about how you will approach this work. Constructively engaging in the conversation sets a starting constructive tone.

The Third Challenge: Do the Work

Once everyone agrees on what actions to take and what success looks like, we begin the third challenge: do the work.

The challenge here is focus. Remember that piece of paper she slid over and had me sign? I asked about that date, which was 90 days in the future. The answer was, “If we don’t fix this by this date, then we will take action.” The date exists to give the plan structure, but it feels like a threat. It sounds like an angry clock ticking in the back of your head, and if all you do is obsess about the ticking, you won’t do the work.

Focus on the work. Back at Borland, I was so new to the industry that I didn’t understand the gig. Borland was experiencing rapid growth, so my manager didn’t spend sufficient time with me, and I was all over the place.

The work:

  • Write test plans that exercise new features.
  • Find defects by executing these test plans and performing ad-hoc spot testing.
  • Report these defects in a manner that is helpful to the folks who will be fixing these defects.
  • Carefully confirm when these defects are reported closed.

That’s it. That was my job. Why was I failing? My memory is hazy, but I think we were many months (years?) away from having a testable product, so I was tinkering. Writing little throw-away automation scripts. Goofing around with a partially implemented product. Waiting for someone to tell me what to do. The features weren’t close to done, so no test plans and no defects were filed, so I tinkered. I goofed around, probably until the paper slid across the table.

Time to work.

Test plans. Yes, the feature was still being built, but two conversations with the engineers in the hallway quickly described what was and wasn’t working. Great, here is the first draft of the test plans for the working portions of the feature. Yes, they would change once the complete feature landed, but a partial test plan both framed my initial thinking and could confirm what was even partially working for engineering.

Find, report, and confirm defects. From the test plan. Yes, most of these defects were never fixed because the product changed so much, but the defects I filed demonstrated that I understood the current state of the product. When the defects were particularly heinous, they were fixed quickly.

And I asked for help. With the angry clock tick tocking in your ear, it’s easy to narrow your focus to what you can do right now, but the clarity you defined in the first challenge will only take you so far. You need help, and while asking might feel like admitting weakness, it builds strength. Your request for help tells those you ask that you care about their opinion and are serious about the work.

The Final Challenge: Exceed Expectations

You will succeed at this performance plan by achieving what your manager describes in the document. The final challenge might be optional, but I think it’s critical. I’ve repeatedly reminded you to face this situation stoically, calmly ask for clarification, and purposefully attack the work, but…

… it’s still a hit. An ego hit. I thought I was doing ok until I wasn’t. I was embarrassed when I realized what was written on the paper and ashamed while considering my next steps that weekend.

The final challenge isn’t just to do the work but to exceed expectations. My approach at Borland and whenever a helpful someone gives me constructive feedback is to hear it, address it, and act on it in a fashion that demonstrates that I am the expert.

My testing area back at Borland was database creation and editing for Paradox for Windows. The user interface to create a database and later change its structure. When I arrived, the user interface did not exist. Databases were being created and edited via the command line or the prior DOS-based version of the product.

My goal: become an expert in this area. Develop a deep understanding of the database’s characteristics, the different record types, performance, and storage characteristics. There was much to know, and little was written down, so I wandered the halls. I badgered the engineers for any data they could share. Yes, just scribble on the whiteboard. That’s fine. Product management? Tell me what you think. Hopes and dreams are fine. Here’s a piece of paper — scribble away. This is useful because, amongst the chaos of developing a 1.0 product, I began to have the clearest view of our goals for creating and editing a database.

Months later. Long after the performance plan was complete, I remember the head of product, an engineering director, and the engineer responsible for the feature walked into my office with a floppy disc. I grabbed the disc, installed the root, and hammered on the latest bits. No automated testing, just me running an ad-hoc smoke test — from memory — to assess the quality of these close to final bits. Took five minutes, and halfway through, the director smiled and looked at the head of product and said, “Told you. He’s the guy.”

I finished, spun around in my chair, and said, “It’s good.” Each of these humans was here because of the relationships I formed when asking endless questions about the product for which I was accountable.

The hardest part of a performance plan isn’t stoicism, understanding, or doing the work. It’s recovering from the gut punch that comes with recognized failure. Exceeding expectations isn’t about doing extra work but building confidence in one’s capabilities.

90 Days and Signature

You’re reading a recap of a performance plan that occurred decades ago, told as an idyllic tale of success designed to educate. I did eventually succeed at Borland, but I’m confident that I said nothing when the paper slid over. I was ashamed. I was depressed that weekend. I didn’t jump into Monday with vim and vigor. I was confused and spiraled into self-pity.

I don’t remember how I turned it around, but it started when I signed this paper that defined a deadline. It started when I accepted the failure of my prior work. I’ve used this practice over and over again through the years because I fail quite a bit. It’s never fun and often embarrassing, but it’s always an opportunity to start a learning process.

I do vividly remember one moment from the following week. I was sitting in a conference room that had been converted into cubes. I was staring dumbly at my screen when my manager walked in, sat on the edge of my desk, and stared at me momentarily before asking, “How are you?”

I responded, “I’m good. Let’s do this.”

So we did.

# 1 Comment on Ok. So, You’re Failing
Rands It's hard to have nice things on the Internet

Just Hard Work

I started this piece in late November. It’s a piece I usually write Christmas as a kick-off to the new year. The precise process by which this yearly piece arrives is a mystery. Probably the mental reset that comes with the New Year. So, what’s with the first draft showing up before Thanksgiving?

As I wrote earlier, I’ve been turtling since the US Election. Mostly avoiding all news, standing up and politely walking away when the conversation sways towards politics, deeply diving back into a video game legend. You know. Classic avoidance.

I’m also writing a new book about — wait for it — that’s right, leadership. This topic was inevitable, but since the election, I’ve been wondering whether there is something original or new to write, given the current circumstances in the United States.

Probably not.

Like many friends, I’ve chosen to focus my efforts on family, community, and work. Attempting to comprehend, let alone influence, the larger narratives on the planet strikes me as a particularly futile effort in what appears to be a post-literate society.

So, at the beginning of this year, I want to tell you a small leadership tale about the Rands Leadership Slack and why it works.

The Rands Leadership Slack is a community I created on June 1st, 2015. It’s, yes, a Slack, and as of this writing, it has almost 35,000 members. Over 5,000 of those members are active every week. There are over 800 public channels, and while many are focused on the craft of leadership, there are hundreds of non-leadership channels. I now play a game where I wonder, “Is there a channel for X?” I find said channel and over 100 members are usually already chatting about the topic.

While I am proud of this blog, the Rands Leadership Slack is the most impactful thing I’ve built outside my family and job. Thousands of community members discuss and learn from each other every day.

And it’s hard to have nice things on the Internet.

Here’s how we do it.

Endless Hard Work

First, there was a bit of luck. I was pretty quick to see Slack would be a good tool for this type of community, but Slack, by choice, was not designed for community. The free plan is designed to give you a taste but not a scalable community. After 90 days (or a certain number of messages?), you must pay to see your history. This was Slack’s chosen business model.

I spoke at Slack before I became the VP of Engineering, and they graciously agreed to comp me a pro edition of Slack with no restrictions. They don’t do this anymore. Don’t ask. This generosity allows us to see the entirety of Rands Leadership Slack, which gives the community memory and history.

Second, there is endless hard work.

I use the process for each application, which you can read about here.

  • Receive an email from an applicant.
  • Read the email and determine if they can follow directions.
  • If they can’t, send them a follow-up email that explains the directions again. This is a template. I don’t type this each time.
  • If they can follow directions, send them the invite plus the onboarding directions, which ask them to read the Code of Conduct. Set their profile image to anything but the default, and once logged in, introduce themselves on intros and drop me a direct message on Slack.
  • If new members directly message me (I feel 40% of the new members do this), respond briefly but thoughtfully.

There was a window where existing members could invite new members, but as I wanted everyone to experience the same onboarding, all applicants now follow the same process. My estimate is that I’ve sent around 39,000 emails (roughly 10% of invited applicants never joined).

39,000. Spread that over nine years, that’s not huge amount of daily work, but it is a process I have consistently followed for almost a decade. Many applicants who are aware of the size of the community assume there is either a small army of admins who handle this or that we’ve got robots doing the work. We don’t. It’s just me. 39,000 mails.

While the size of the community is an essential aspect of the community, this is not what makes it valuable.

Listen, Understand, and Learn

Given the by-design upfront choice not to open the floodgates on user growth has never been outrageous; it has been steady. This gentle and mostly predictable user growth means that social breakdowns that occur when many strangers are suddenly shoved together don’t occur… as fast.

Around the five thousand-member mark, we had the first community request for a Code of Conduct. We had the first serious issue with a member where it was clear that I, the only admin at the time, would need to act. But how? And based on what? My random judgment? At that time, I had this aspirational but erroneous belief that because it was a leadership community, members would bring their best leadership skills to the table, and the Code of Conduct or other cultural artifacts were unnecessary.

My resistance to calls for a Code of Conduct and subsequent additional requests for a formal administration team was impressive… and delusional. I was in New York at the time and spending multiple hours each morning with requests for comment from the community when I finally threw up my hands, found what looked like a good Code of Conduct on the Internet, branched it, touched it up with a smidge of Rands™, and sent it to the complainers.

“Happy now?”

“Yes.”

wut.

The magnitude of the impact of the decision to create our Code of Conduct dwarfs my decision to keep growth sensible by designing a robot-unfriendly complex application process. The fact that it exists addresses many initial concerns of the community. Its regular use in conversations within the community gives us a useful playbook for deconstructing complex people issues. Most of every week since the Code of Conduct landed, I’ve used to explain a bit of this community to another member. Most months, I take time to edit it to help clarify the thinking laid out in the artifact. Policy changes land in the document multiple times a year because I do what I initially failed to do when the community asked for its existence — I listen.

When I realized the single best feedback source on what the community needed was the community, my job became obvious. Not enforcer, but educator. This feedback does not arrive conveniently. It’s usually packaged inside high drama. Two or three, or fifty members are ready to fight. Tempers are often high. When they show up, I clench my jaw and remember that while they might not know it, they are teaching me about the community, and I have to listen to understand the lesson. I have to empathize with the concerns, but not so much that I participate in the often heated emotions. My job is to ask questions to gather as many perspectives as possible. Finally, I must decide: “Does our Code of Conduct help resolve this situation? Or does it need to evolve?”

I need to find the lesson and then do the work to teach that lesson to everyone else.

Lead Peacefully

One of the favorite lines from the Code of Conduct:

“As a leadership community, we believe peer-to-peer discussions, feedback, and corrections can help build a stronger, safer, more informed, and more welcoming community.”

I interview and hire a new set of admins every two years, and within a few months of their start, a new conflict emerges in the community. As new admins, they ask me for advice, and I point them at this part of the Code of Conduct and ask some version of it: “Did you see if they attempted to resolve the situation themselves? It is a leadership Slack, after all.”

“But shouldn’t we help?” they ask.

“We are helping by suggesting they use their leadership skills to attempt to resolve this situation by themselves.”

It’s easy to make instant emotional assumptions about other humans, especially after decades of training on social networks. Our culture asks members to do the work, step outside of themselves and consider the perspectives of others to find a lesson they might not have seen. It doesn’t always work, but it’s where we start.

RLS will celebrate its 10th anniversary later this year. It is the highest-quality, most inclusive, and most authentic leadership community on the planet.

And it only took one hack: Hard work. All the time.

Happy New Year.

# 3 Comments on Just Hard Work
Management Impending doom. Just the hint of it.

Managing Up

My problem with the phrase “Managing Up” involves a hard-earned historical observation regarding its weaponization. The helpful version of this practice is a clear understanding between you and your manager that there are uncommon, intriguing, or worrying developments that you — without hesitation — share with your manager.

Isn’t that their responsibility, as well? It is. Also, wouldn’t you expect them to have significantly more of these observations because their observational blast radius is larger? They do. Do we call this “Managing Down”? Gross. No, we call this bi-directional effective communication, which is a mouthful. This is also only half of a correct strategy.

“Managing Up” is problematic because it often describes a subset of humans who perform this task, believing, “I am artisanally selecting the most important bits of information to share upwardly because my judgment is incredibly sound.”

This is not what they are doing. What they are doing is manipulating perception. They have a specific selfish narrative they want their manager to build, so they carefully select a subset of the truth and market it as the complete picture. They believe their manager is so busy and soup tasting that their interpreted version of the story will become canonical.

Bad news, truth tweakers. A competent leader will source their facts. They will share that partial story with a trusted other not because they don’t trust you but because a story must defend itself, stand up to scrutiny, and prove its worth. They don’t do this because they don’t believe you; they do this because it’s perfectly reasonable communication hygiene. When they discover you’ve delivered half the story, they will quietly ask themselves, “Why half? Are they trying to save me time, or are they trying to lead me astray?” One occurrence of this behavior is no big deal. A small error. Two occurances? Is this a pattern? Probably not. Wait, three? Ok, why are they deliberately choosing to tell me a dubious version of the truth?

Managing up. If you were drawing a word cloud of dubious management-related phrases, chances are, “Managing Up” would be proximate to “Kissing Ass.” To me, “Managing Up” has that “your boss’s job is more important than yours” feel, which pisses me off.

Your boss isn’t more important than you; it’s different. You are responsible for yourself and the professional well-being of your team of seven engineers and your product. Your boss is responsible for her job, you, your six peers, their 57 respective employees, and the four products. That’s 72 humans and five products if you’re keeping count.

As you move “up” the organization chart, the amount of responsibility that weighs on a manager increases significantly, and, yes, this does mean they often make more money than you, but that is often because they have more years of experience. This experience allegedly means they can complete a more diverse set of work at vaster scale because they are you in 5-10 years, but — I remain steadfast — it’s different work.

But each of you has equal responsibility for sharing information.

Essential Information

Okay, thanks for letting me vent. With that out of the way, let’s get practical.

The amount of aggregated information you need to do your job increases as a function of the magnitude of your responsibility. This means you must become adept at finding, confirming, understanding, and passing it along in the correct direction.

That’s what you’re looking for — information that has passed through the bright minds of your team, where they’ve coalesced the vast amount of information they see into informative, crisp narratives. One challenge is they know you have six other leaders doing precisely the same thing, so they need to prioritize and choose which narratives to share.

What’s important to share? I’m glad you asked. There are three areas where the information requires constant vigilance:

  • Projects — the things you build, the large tasks you complete, and the significant work involving many humans.
  • People — all the humans around you in every direction helping you complete the projects.
  • Politics — the connective communication that binds all the humans together — easily manipulated for good and evil.

In this piece, I will explain the projects, people, and political developments you always want to share — no matter what. While I will strive to make this complete, there is one type of development you must always report:

Unexpected developments. A situation appears in front of you, a non-threatening one but unexpected. Strange. Something is up, but you can’t discern the backstory story or the intent. It is unfamiliar. Tell your manager. Now. Just a brief note. A heads up. It’s probably nothing — it usually is — but there is a chance your manager’s context plus your suspicions equals additional clarity.

I want to start by acknowledging a fundamental professional tension. Your managers want you to believe you can do your job without them (which everyone wants, by the way), but when you fail to keep them informed about important developments within the team, it looks like you don’t know how to do your job (which no one wants, by the way). Confusingly put, neither you nor your manager is doing your job correctly when you’re sharing too much or too little information.

Here are the areas:

People

  • A significant unexpected change for a key individual on the team. Life situation, odd conversation that doesn’t add up, or, again, a perception that something is up.
  • Major successes. It needs to be communicated even if it was supposed to happen like this for them. Exceeding expectations is worth noting. Every time.
  • For humans on your team, with an agreed-upon growth plan you’ve shared with your manager, you report minor successes against this plan. Failures, too.
  • Anytime ever that anyone ever thinks about saying the words or phrases “Human Resources,” “People Team,” or “Legal.” Even if they claim to be joking, the fact they are thinking of these teams is a fact that must be shared.

Projects

  • A significant positive or negative development on a critical project. Not the resolution but the observance of the development at first sight. This is even more critical when your manager has a professional stake in the project’s outcome.
  • Projected-related gossip from external high-trust parties. Might be gossip. Might be an early warning system. Could be political. Keep reading.
  • Achieved milestones. Missed milestones. Contributing factors and recommended fixes are appreciated for those missed milestones, but waiting until these are perfectly defined is often a tactic motivated by not wanting to share bad news. The sooner I hear bad news, the more I can help.
  • Impending doom. Just the hint of it. A slight smell in the air.

Politics

  • Interesting developments on external teams where we have a project dependency.
  • Gossip, rumors, and lies about the project. Yes, much of this information is false, but the fact these rumors are wandering the hallways is news. Folks are spreading this misinformation for a reason that is worth discovering. True story: there are humans out there who insert lies into the organizational bloodstream to see the reaction. They call this pressure testing, and these humans are jerks.
  • Just. Plain. Weird. Yeah, it’s a catch-all. Yeah, it’s the hardest to define, but sometimes people say the darndest, strangest things, and rather than scratching your head and staring at the ceiling, tell someone else this weirdness and see what happens.

Do all this consistently with your manager and team; again, you’re working with half the information.

Managing Sideways

My actual problem isn’t with “Managing Up” or “Managing Down”; if you do this well, you’re still only working with half the necessary information. You and your manager collectively represent half the information required to do your job. HALF.

Look to your right. Look to your left. That’s the other half, and you’re probably ignoring much of it. It took me a couple of decades to properly value horizontal relationships and their context. Why? Because everyone kept asking me if I was “Managing Up”. [facepalm] My manager told me what to do; they set my compensation, so I managed the relationship because they managed me.

People, projects, and politics. Your relationship with your manager represents half the information you need, half the context. It doesn’t mean you can’t do your job, but it’s not a stretch that you are missing critical developments because of the absence of this context.

If you don’t believe me, it’s because the lesson hasn’t been hammered into you by the path of senior leadership, where you become increasingly distant from the measurable familiarity of hands-on work and become adept at building a sense of satisfaction and productively finding, confirming, understanding, and passing along critical information.

And you are not doing this alone.

# 2 Comments on Managing Up
Rands Seek understanding

The Cleanse

I’m in the midst of a media cleanse. This started before the election when I canceled my Washington Post subscription. Jeff Bezos can do whatever he wants with the Washington Post, and he’s 100% correct that I don’t trust large media organizations.

After the election, I removed all news sources from Feedly except the Atlantic because I find their writing informative and compelling.

A friend calls this turtling. Pulling your head inside your shell and hiding. It’s quite comfortable here. With most of my free time, I’m leveling a dragon Holy Priest in World of Warcraft. #ama

Next on the list is Twitter. Since it was sold and turned private, my engagement has been significantly lower, and my follower count has shrunk as the humans have moved off the platform, but quite soon, I’m deleting my account. My finger has been over the DELETE button for a few days, and I’ve wondered why. Two facts: First, there are thousands of folks with whom I share stuff there. I can see they are there via much reduced but real engagement. Second, I have just under 20k tweets since 2007 that, upon review, tell an interesting story… at least to me.

I’ve downloaded the complete archive, and I’m sad to say I’m about to create a bunch of 404 errors when my corpus of tweets vanishes from Twitter. Why? This is my content, and I don’t want whatever Twitter has become to benefit from its existence. I’ll share the archive here at some point, but for now, I’m cleansing.

Like FaceBook before it, Twitter turned into something else. They both, early on, felt like a means of connection. Unfortunately, building that social graph allowed these businesses to target you and your engaging, clickable content expertly. What was a means of connection turned into hot, juicy, bite-sized content. Over the past two decades, this practice has made us intellectually lazy because these media services are paid not on the quality but the quantity of service. More clicks, more engagement. Truth and facts. Optional.

And what was a clever means of connection turned into a raging stream of clickable things.

So, bye, Twitter. I’m late to the funeral, but better late than never. It was fun before it got terrifying.

While I am profoundly turtling and have little desire to see a path forward, I have two related observations:

First, the lack of healthy debate on most social media is one of the core issues with the platform. Humans must disagree, but these platforms do not provide a proper bi-directional medium (or set of tools) for these debates. It’s liking, then not liking, then yelling, then ALL CAPS, and NOW I’M UNFOLLOWING YOU and YES BLOCKING BYE.

Debate is a tricky act between two humans who can both speak, listen, understand, and possibly evolve. Two humans. Often, there will be more, but let’s keep it simple and assume it’s two. Both humans are required to do this, and in the primarily anonymous world of social media, it’s normal not to consider the other human a human. They are the last thing they wrote that you disagree with. There is no relationship; it’s simply the last thing they posted. And how do you feel about that post.

The stakes are higher in person. You have to stare at that human in the eye, especially after they say something you don’t like. So, what do you do? You can’t yell, you can’t ignore them, and you certainly can’t block them, so what is your move? Mine: seek understanding. Put on that empathy hat and try to understand why they’re saying what they’re saying. That’s the first step. There are many more — read the book.

The continual failure to do this in social media results in a growing echo chamber where the humans agree, and those who disagree are quickly voted off the island. Some of these echo chambers are low stakes. Think about your favorite sports team. Those fans are aligned on what’s important. Who needs debate? The only debate we care about is what $OTHER-TEAM we hate the most. Go $OUR-TEAM.

There are higher-stakes echo chambers, too. Use your imagination here.

Second, it’s not a short or medium-turn fix to what ails us, but I am curious about investing in local and independent news organizations. Large media organizations have to compete with social. They desperately need those clicks, and that means mimicking the patterns they see in social. The headline must engage in one second or less, or it will be forgotten. It’s an economy of attention, not understanding or truth.

Local media has taken it on the chin for decades because social media consumes advertising dollars. Local media has withered without that support, with remaining big media sources bending to social media engagement patterns. The idea of investing in local media news organizations is because they report on the events that happen in my neighborhood. This makes them more human to me. They have skin in the game because, like me, they live here. My problems are their problems, which means we have a solid foundation to start to understand.

How do I go about this investment? Where do I start?

I don’t know. I’m turtling. For now.

# No Comments on The Cleanse